System and Method For Managing One Or More Games Of Chance Over A Network

ABSTRACT

Implementing games of chance across multiple computing devices is described. An electronic hand is associated with each computing device. The electronic hand includes a set of characters having a value. An electronic bid, which is a total quantity of a character of the set characters at a particular value, is initiated. An electronic challenge to the electronic bid is initiated. An actual quantity of the character at the particular value in the bidding electronic hand is determined. A point value is allocated to the bidder if the actual quantity of the character at the particular value is greater than or equal to the total quantity of the character at the particular value in the electronic bid. The point value is adjusted based on a bid value, and/or bid level, and/or the number of participants.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. application Ser. No.15/054,029 filed Feb. 25, 2016 which is a continuation of U.S.application Ser. No. 14/634,334 filed Feb. 27, 2015, now abandoned, theentire disclosure of which is incorporated by reference into thisapplication.

TECHNICAL FIELD

The present disclosure relates to a system and method for managing oneor more games of chance over a network.

BACKGROUND

Multi-player computer games are in demand. Advances in communicationnetworks and increased computing speeds have nurtured this market andallowed developers to meet this market need. Numerous games are nowavailable through the various application stores online and or throughother web-based portals. While demand is high, competition is fierce anddifferentiation among available games within a category is essential forsuccessful game development and deployment. Games of chance, such aspoker, Liar's poker and others, have been implemented through webportals prior to widespread use of gaming platforms, such as Apple'sGame Center and others. Early online versions of games of chance simplyreproduced graphically on a computing device the basic game format andrules of play. These early versions lacked functionality that improvedhow various networked computing devices interact to escalate the levelof play during a game.

SUMMARY

Embodiments of the present disclosure include a system and method forimplementing one or more games among a plurality of computing devicesthat are associated with a respective plurality of game participants.The method can include associating an electronic hand with each one ofthe plurality of game participants and the electronic hand including aset of characters with each character having a value. The method caninclude receiving an electronic bid from one computing device of theplurality of computing devices, wherein the electronic bid is anindication of a total quantity of a particular character of the setcharacters at a particular value among each electronic hand associatedwith the respective plurality of game participants. The method caninclude receiving an electronic challenge concerning the electronic bidfrom each remaining computing device of the plurality of computingdevices. The method can also include determining an actual quantity ofthe particular character at the particular value among each one ofelectronic hands associated with the respective plurality of gameparticipants. In response to receiving the electronic challenge fromeach remaining computing device of the plurality of computing devices,the method includes the step of comparing the actual quantity of theparticular character at the particular value to the total quantity ofthe particular character at the particular value in the electronic bid.The method includes allocating a point value (or number of units) to thegame participant associated with the one computing device if the actualquantity of the particular character at the particular value is greaterthan or equal to the total quantity of the particular character at theparticular value in the electronic bid, wherein the point value isadjusted by a multiple determined by A) at least one of a bid value andbid level, and B) the number of game participants, the bid level beingthe total quantity of particular characters in the electronic bid.

Another embodiment is a system that includes a computer processorconfigured to associate an electronic hand with each game participant,each electronic hand including a set of characters, each characterhaving a value. The system can include a computer memory having storedtherein in response to receiving 1) an electronic bid from one computingdevice of the plurality of computing devices, wherein the electronic bidis an indication of a total quantity of a particular character of theset characters at a particular value among each one of the electronichands that was allocated to the respective plurality of gameparticipants, and 2) an electronic challenge concerning the electronicbid from each remaining computing device of the plurality of computingdevices. The computer processor is further configured to A) determine anactual quantity of the particular character at the particular valueamong each electronic hand, B) compare the actual quantity of theparticular character at the particular value to the total quantity ofthe particular character at the particular value in the electronic bid,and C) allocate a point value to the game participant associated withthe one computing device if the actual quantity of the particularcharacter at the particular value is greater than or equal to the totalquantity of the particular character at the particular value in theelectronic bid. The point value increases by a multiple determined by a)at least one of a bid value and a bid level, and b) the number of gameparticipants, the bid level being the total quantity of particularcharacters in the electronic bid.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofan example embodiment of the application, will be better understood whenread in conjunction with the appended drawings, in which there is shownin the drawings example embodiments for the purposes of illustration. Itshould be understood, however, that the application is not limited tothe precise systems and methods shown. The patent or application filecontains at least one drawing executed in color. Copies of this patentor patent application publication with color drawings will be providedby the Office upon request and payment of the necessary fee. In thedrawings:

FIG. 1 is an exemplary diagram illustrating a plurality of computingdevices each associated with a game participant and a gaming platformfor implementing a gaming application for a game of chance, according toan embodiment of the present disclosure;

FIG. 2 is an exemplary computing device illustrated in FIG. 1;

FIG. 3 is an exemplary data table created via the gaming applicationused to associate electronic hands with each game participant anddetermine the sequence of rounds for a game session;

FIG. 4 is a process flow diagram illustrating a method for implementinga game session across the plurality of networked computing devicesillustrated in FIG. 1;

FIG. 5 is a front view of a graphical user interface for a displayscreen or portion thereof, illustrating an exemplary start screen for agaming application for a game of chance according to an embodiment ofthe present disclosure;

FIG. 6 is a front view of a graphical user interface for a displayscreen or portion thereof shown in FIG. 5, illustrating an exemplaryscreen used to initiate a multi-player game in the gaming application;

FIG. 7 is a front view of a graphical user interface for a displayscreen or portion thereof shown in FIG. 6, illustrating an exemplaryscreen displaying multiple running game sessions in the gamingapplication;

FIG. 8 is a front view of a graphical user interface for a displayscreen or portion thereof shown in FIG. 7, illustrating an exemplaryscreen displaying a player's interface during a round of play on thegaming application and showing bid and challenge options;

FIG. 9 is a front view of a graphical user interface for a displayscreen or portion thereof, illustrating an exemplary screen displaying aplayer's interface during a round of play as shown in FIG. 8, butillustrating bid and count options;

FIGS. 10A and 10B are front and detailed views, respectively, of agraphical user interface for a display screen or portion thereof,illustrating a game slip that includes both played and unplayed hands;and

FIG. 11 is a front view of a graphical user interface for a displayscreen or portion thereof, illustrating an exemplary screen displaying aprogression of multiple played rounds of a game session.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present disclosure includes a system, method, and associatedsoftware gaming application for implementing a multiplayer game ofLiar's poker over networked computing devices. In the basic version ofLiar's poker, each player is dealt a U.S. monetary note, such as adollar bill with the “hand” being the 8-digit serial number on the note.Through successive bidding, players try to determine the total quantityof a particular digit across all hands knowing only their own hand andinferring what others may have through their bids, which may or may notbe truthful. Once a bid is made it must subsequently be raised orchallenged. When all players challenge a bid, a count of the particulardigit across all hands determines if the bidder has won or lost, inequal amount from or to the other players. The present disclosureincludes a version of Liar's poker implemented as a gaming applicationrunning across multiple computing devices with additional functionalfeatures that modify play based on inputs from each computing device.The gaming application facilitates implementation of the game overdistributed, networked computing devices. The result is improved gamefunctionality and player experience.

Referring to FIG. 1, the game system 10 includes a plurality ofcomputing devices 20 a, 20 b, 20 c, . . . , 20 n, and 25 in electroniccommunication with each other via network. The computing devices 20 a-20g may be associated with a gaming platform 30, such as Apple's GameCenter, Google's Game Play, or other similar platform. The gamingplatform 30 is illustrated schematically in dashed lines in FIG. 1. Forpurposes of clarifying how the gaming application is implemented acrossmultiple computing devices, reference number 20 is used interchangeablywith reference numbers 20 a, 20 b, 20 c . . . , 20 n, and 25, unlessnoted otherwise. Each computing device 20 may be associated with a gameparticipant. Each game participant can participate in a game byassociating their computing device 20 with the gaming platform 30. Onceassociated with the gaming platform 30, the game participant can enterand participate in games with other game participants as will be furtherdetailed below. FIG. 1 illustrates computing devices 20 a, 20 b, 20 c .. . 20 n and 25 associated with the gaming platform 30.

Continuing with reference to FIG. 1, the game system 10 is implementedvia exemplary architecture that includes computing devices 20 a, 20 b,20 c . . . , 20 n in electronic communication with each other via acommon communications network, such as, for example the Internet. Asillustrated, the computing devices 20 a, 20 b, 20 c, . . . , 20 n arearranged in a client-server architecture. In the illustrated embodiment,computing device 25 can function as a server-type computing devicededicated to hosting a portion or all of the gaming softwareapplication. The server-type computing device 25 also receives andtransmits data regarding each hand of a game to all other computingdevices associated with a particular game. When the gaming applicationhas been installed on the server-computing device 25, the gamingapplication can transfer information between other computing devices viathe common network. It should be appreciated that one or all thecomputing devices 20 can receive information from the other computingdevices. One or all of the computing devices 20 can also transmitinformation to the other computing devices. Further, one or all of thecomputing devices 20 can access information on the other computingdevices. “Access” or “accessing” as used herein can include retrievinginformation stored in memory on a computing device. For instance,“access” or “accessing” includes sending instructions via the networkfrom computing device 25 to computing device 20 a so as to causeinformation to be transmitted to the memory of the computing device 20 afor access locally by the computing device 20 a. In addition oralternatively, “access” or “accessing” can include the computing device25 sending an instruction to computing device 20 a to access informationstored in the memory of the computing device 20 a. Reference tocomputing devices 20 a and 25 in this paragraph is exemplary and areused to only clarify use of words “access” or accessing.”

FIG. 1 illustrates a client-server network. But the gaming applicationcan be implemented over any number of network configurations. Forexample, in alternate embodiments, the computing devices 20 a, 20 b, 20c . . . , 20 n are configured as a peer-to-peer network architecture. Instill other alternative embodiments, the computing devices 20 a, 20 b,20 c, . . . , 20 n can be arranged in a ring-type network architecture.Further, the gaming application can be implemented across computingdevices arranged on a network that includes aspects of a client-servernetwork, peer-to-peer network, ring-type network, and/or other networkarchitectures known to a person of ordinary skill in the art.Accordingly, it should be appreciated that numerous suitable alternativecommunication architectures are envisioned.

Referring FIG. 2, the computing devices are configured to receive,process, and store various information used to implement the gamingapplication. Computing devices 20 a-20 g and 25 are similar and for easeof illustration only computing device 20 will be described below. Thecomputing device 20 may be configured to run one or more softwareapplications, including the gaming application that implements a game ofchance, such as an enhanced version of Liar's poker. It will beunderstood that the hardware components of computing device 20 caninclude any appropriate device, examples of which include a portablecomputing device, such as a laptop, tablet or smart phone, or othercomputing devices, such as a desktop computing device or aserver-computing device. As illustrated, the computing device 20includes one or more processors or processing portion 202, a memory ormemory portion 204, an input/output 206, and a user interface (UI) 208.It is emphasized that the block diagram depiction of the computingdevice 20 is exemplary and not intended to imply a specificimplementation and/or configuration. The processor 202, memory 204,input/output portion 206 and user interface 208 can be coupled togetherto allow communications therebetween. As should be appreciated, any ofthe above components may be distributed across one or more separatedevices and/or locations.

Continuing with FIG. 2, in various embodiments, the input/output portion206 includes an antenna or an electronic connector for wired connection,or a combination thereof. In some implementations, input/output portioncan include a receiver and transmitter, transceiver ortransmitter-receiver. The input/output 206 is capable of receivingand/or providing information pertaining to communication with a networksuch as, for example, the Internet. As should be appreciated, transmitand receive functionality may also be provided by one or more devicesexternal to computing device 20. For instance, the input/output 206 canbe in electronic communication with the receiver.

Depending upon the exact configuration and type of processor, the memory204 can be volatile (such as some types of RAM), non-volatile (such asROM, flash memory, etc.), or a combination thereof. The computing device20 can include additional storage (e.g., removable storage and/ornon-removable storage) including, but not limited to, tape, flashmemory, smart cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic storage orother magnetic storage devices, universal serial bus (USB) compatiblememory, or any other medium which can be used to store information andwhich can be accessed by the computing device 20.

The computing device 20 can contain the user interface 208, which caninclude an input device and/or display (input device and display notshown) that allows a user to communicate with the computing device 20.The user interface 208 can include inputs that provide the ability tocontrol the computing device 20, via, for example, buttons, soft keys, amouse, voice actuated controls, a touch screen, movement of thecomputing device 20, visual cues (e.g., moving a hand in front of acamera on the computing device 20), or the like. The user interface 208can provide outputs, including visual displays, such as exemplarydisplay screens illustrated in FIGS. 5-11. Other outputs can includeaudio information (e.g., via speaker), mechanically (e.g., via avibrating mechanism), or a combination thereof. In variousconfigurations, the user interface 208 can include a display, a touchscreen, a keyboard, a mouse, an accelerometer, a motion detector, aspeaker, a microphone, a camera, or any combination thereof. The userinterface 208 can further include any suitable device for inputtingbiometric information, such as, for example, fingerprint information,retinal information, voice information, and/or facial characteristicinformation, for instance, so as to require specific biometricinformation for access to the computing device 20. It should beappreciated that the computer devices can operate via any suitableoperating system, such as Android, BSD, iOS, Linux, OS X, QNX, MicrosoftWindows, Windows Phone, and IBM z/OS. Furthermore, the gamingapplication can operate with any of the aforementioned operationsystems.

How the game of chance is implemented across a plurality of computingdevices 20 will be described next. Typically a player installs a versionof the gaming application on their respective computing device 20. Whenmultiple computing devices 20 are running the gaming application and arein electronic communication with the other via the gaming platform 30,information concerning the game can be displayed via the user interfaceon each computing device. In general, each player is “dealt” anelectronic hand for a round of play. Multiple rounds of play comprise a“SLIP” or “Slip”, and one or more Slips comprise a game session. Asexplained below, the gaming application executed by the processor 202“deals” electronic hands by associating electronic hands with acomputing device and its respective game participant. An electronic handincludes a set of characters each having a value. Each character valuecan be randomly generated. In any particular electronic hand, the valueof the character may be unique. It is not necessarily true in everycircumstance that the value of the character will be completely unique.For example, the probability of the gaming application generating twoidentical electronic hands is very low. In the described embodiment, theelectronic hand is an 8 digit alphanumeric character set. In oneexample, the electronic hand can include an 8-digit number, such as“51898756.” The electronic hand can include fewer than 8 digits or morethan 8-digits. In just one example, the electronic hand corresponds toserial numbers on U.S. monetary notes, such as a dollar bill. In anotherexample, the electronic hand can include an 8-digit letter set, such as“BFAYFAMN.” The word “value” when associated with an electronic hand isthe relative value with reference to other characters. For example, thevalue of the character is one of the numbers 1, 2, 3, 4, 5, 6, 7, 8, 9,and 0. In one embodiment, value increases from 1 to 0 such that “0” isassigned a greater value than 1, 2, 3, 4, 5, 6, 7, 8, and 9. In such anembodiment, “0” has a greater value than “9,” “9” has a greater valuethan “8,” etc. In other embodiments, the value of “0” is assigned avalue less than the value of 1, 2, 3, 4, 5, 6, 7, 8, and 9. In such anembodiment, “1” has a greater value than “0,” “2” has a greater valuethan “1”, etc. The gaming application is configured to randomly assignelectronic hands to each player and their computing device for eachround of play. In one embodiment, the players would have differentelectronic hands for each round or SLIP. Randomly assigning electronichands to each player during each round can prevent any one player fromobtaining an advantage by “learning” other players hands when playingfrom one SLIP to another SLIP with the same group of players.

During a round of play, a player bids on (or challenges) using thecomputing device, a total quantity of a particular character among eachelectronic hand held by all of the players in the game. A bid is anestimate of the total quantity of a particular character across allhands at a particular value. Each player can also review the otherplayer's electronic bids, bid history, and other data concerning thegame. A winning bidder receives points or units from each player.Accordingly, point values are allocated to each player depending on theoutcome of the particular round and bids/challenges. For instance, if afirst player makes a certain electronic bid, is challenged, and thegaming application determines the first player's bid was correct, thegaming application allocates points to the first player. If the firstplayer loses the challenge, points are allocated to every other player.The point values may be stored for each round and a running total for anumber of rounds (such as a game session) may be displayed in eachcomputing device as further detailed below. In at least one example,there are a limited number of points available for allocation among eachgame participant so that progression of each round in such an embodimentresults in a “zero-sum” game. The gaming application includes additionalfeatures, such as “multiples” and special bid types, e.g. “none-bids”and “hero-bids” that escalate the level of play among the game players.More specific details concerning how the game is implemented overnetworked computing devices will be described next.

The gaming application can manage a game session that includes betweentwo and up to twelve participants in a round of play. In one embodiment,the game session can include two participants. In another embodiment,the game session can include three participants. In another embodiment,the game session can include four participants. In another embodiment,the game session can include five participants. In another embodiment,the game session can include six participants. In another embodiment,the game session can include seven participants. In another embodiment,the game session can include eight participants. In another embodiment,the game session can include nine participants. In another embodiment,the game session can include ten participants. In another embodiment,the game session can include eleven participants. In another embodiment,the game session can include twelve participants. It should beappreciated that the game session could include more than twelveparticipants, such as twenty or more. Furthermore, more than one gamesession can be running at any given time.

FIG. 3 illustrates an exemplary data table for compiling a game session300 that organizes multiple rounds of play 310 and electronic hands 350for each player. As shown in FIG. 3, the rows include a row identifier312 for the rounds of play 310, illustrated as rows A through Q, and thecolumns represent each computing device and its associated player 1, 2,3 . . . n. A cell where a row and column intersect represents anelectronic hand for the particular player for a given round. Asillustrated, each round of play 310 includes a plurality of theelectronic hands 350 a, 350 b . . . 350 n, each of which is associatedwith a different player's computing device. For instance, in round A, afirst electronic hand 350 a will be associated with the first computingdevice 20 a of a first game player 1. A second electronic hand 350 bwill be associated with a second computing device 20 b of a second gameplayer 2. A third electronic hand 350 c will be associated with a thirdcomputing device 20 c of a third game player 3. A fourth electronic hand350 d will be associated with a fourth computing device 20 d of a fourthgame player 4. Additional electronic hands 350 n will be associated withadditional computing devices 20 n for each additional game player n.

Continuing with reference to FIG. 3, the game session 300 (sometimesreferred to as a “SLIP”) progresses with an initial round where eachplayer initiates electronic bids (or challenges) as noted above. A roundmay be completed when 1) all the players challenge a previous electronicbid, and 2) a count is initiated. A count is initiated at the electionof the bidding participant or a count is forced after all gameparticipants challenge a successive bid by the same bidder. After thecount is made and points are allocated, another round is initiated andthe bid-challenge sequence repeats for each player. The session 300illustrated includes 15 rounds of play denoted as A through Q. Therounds of play 310 are selected based on progression of the game andnature of the bids during play and will be described in more detailbelow. Further, for each new game session, the gaming application cangenerate a new series of rounds and new electronic hands for eachparticipating computing device 20. It should be appreciated that thesession 300 can include fewer than the 15 rounds or may also includemore than 15 rounds.

FIG. 4 illustrates an embodiment of a method 400 for implementing thegame of chance over the system 10 described above. For ease ofillustration, method 400 described below refers to the server computingdevice 25 and computing device 20. Each prospective player or gameplayer associates their respective computing device 20 with a gamingplatform 30 (FIG. 1) as noted above. In some embodiments, prospectiveplayers can purchase a software application that implements the game ontheir associated computing device 20. For example, each prospectiveplayer can purchase the gaming application via Apple's App Store anddownload the gaming application into the memory portion of the computingdevice 20. It should be appreciated that certain aspects of the gamingapplication are executed “locally” on each game participant's computingdevice, such as computing devices 20 a-20 g (FIG. 1), while otheraspects of the gaming application are executed on the server-typecomputing device 25 (FIG. 1). Further, each player may have an accountassociated with the gaming platform and/or the gaming application. Theplayer's account includes a unique identifier associated with a singlegame participant. A player may logon to the participant's account usingany particular computing device that includes the gaming application.

In block 402, a game participant initiates a command via the userinterface on their respective computing device 20 to invoke the gameapplication. Process control is transferred to block 406. In block 406,the computer processor, for example running on computing device 25 (FIG.1), can determine if the computing device 20 is signed onto an existinggame. If the computing device 20 is not signed onto an existing game,process control is transferred to block 410 and the player isauthenticated. After authentication, process control is transferred toblock 414. If, however, in block 406 a determination is made that thecomputing device 20 is signed into the application, process control istransferred to block 414.

In block 414, the computing device 20 can either join a particular gamesession among the one or more game sessions that may be active orinitiates a new game session. Process control is transferred to block416. In block 416, the turn order is set. “Turn order” signifies theorder in which each respective game participant bids/challenges during around. When the turn order is set in block 416, process control can betransferred to block 418.

In block 418, each electronic hand is associated with a respectivecomputing device. In this manner, the gaming application “deals” eachparticipant an electronic hand that is displayed via the user interfaceon the computing device 20. The electronic hand is based on theparticular hand determined for the session and round.

When the electronic hands are assigned, the processor can compile asequence of play. The sequence of play may be compiled in block 418 orany other stage of the game. For instance, the sequence of play can becompiled at a particular phase of the game, stored in memory, andapplied as needed throughout game play. Alternatively, the sequence ofplay can be compiled as the game progresses. In any event, the processorcan arrange a number of rounds, among all possible plurality of rounds(see rows A-Q in FIG. 3), for the game session into a particularsequence of play. The sequence of play can be based on a quantity of aparticular character in each electronic hand in one or more of theplurality of rounds. In just one example, once the gaming applicationhas compiled the SLIP with fifteen rounds A through Q (as illustrated inFIG. 3), the gaming application cycles through a sequence of play thatincludes ten rounds out of the fifteen total rounds. The sequence ofplay initiates with an initial round A of electronic hands 350 a-350 das shown in FIG. 3. Each subsequent round in the sequence of play isdetermined by skipping the number of rounds equal to the number of oddnumbers in the last digit of each electronic hand for that round. Forexample, as illustrated with session 300 as an exemplary data set, theprocessor determines that the first round of electronic hands 350illustrated as “Row A” includes only one odd number in the last digit(see electronic hand 350 b). Based on that determination, the processordetermines that the next, or second round of play is illustrated as RowC. The second round of play illustrated as Row C includes three oddnumbers in the last digit of the electronic hands. Based on the secondround of play, the processor determines the next, or third round of playis illustrated as Row G in FIG. 3. The third round of play includesthree odd numbers in the last digit (see participants 1, 3, 4, Row G).The processor determines that the next, fourth round of play is Row L asillustrated in FIG. 3. The fourth round of play includes one odd numberin the last digit (see participant 1, Row L). The processor determinesthat the next, fifth round of play is illustrated as Row N in FIG. 3.The sequence of play continues in this manner through ten rounds of playto complete a game Slip. If, however, the processor determines that thenext round of play is Row Q as illustrated in FIG. 3, the processorcounts the number of odd numbers among each electronic hand in Row Q. Asillustrated in FIG. 3, Row Q includes two odd numbers in the last digitof each electronic hand (see participants 2 and 4, Row Q.) The processorthen cycles through rounds beginning at the top, skipping completedrounds. In such an example, the round of play after Row Q will be Row F(skipping Rows B and D, and the already played rounds illustrated asRows A, C, and E). In other words, in order to determine the sequence ofrounds, the processor cycles through each of the fifteen rounds Athrough Q until ten rounds of play are determined.

It should be appreciated that a sequence of play can be developedaccording to any number of modifications to the methods and operationdescribed above. For example, any number of possible rounds can becompiled to develop the sequence of play. While 15 possible rounds A-Qare shown in FIG. 3, more than 15 or fewer than 15 possible rounds canbe used. In further examples the sequence of play can include more thanten rounds. For example, up to 20 or 30 rounds can define a sequence ofplay. In still further alternatives, fewer than 10 rounds may define thesequence of play. In another example, the sequence of play can beassigned randomly, prior to the initiating the game. In alternativeembodiments, the gaming application can be configured to permit eachplayer to select their particular hand on a game session 300 or SLIP.For instance, a first player may be permitted to select row or hand A, asecond player could select Row (or hand) C, and third player can selectRow M. Player hand selection can be provided as an in-applicationpurchase or as a wholly separate application. Selection of a “SlipsSelect” input icon on the user interface (not shown) can invoke a methodof obtaining payment and/or purchase authorization. Upon paymentauthorization, the hand selection functionality is operable within thegaming application.

In block 418, the gaming application applies a starting multiple to around of play. Later in the game, in block 450, multiples for subsequenthands are set and applied to the round of play. Regardless, the gamingapplication is configured to determine and implement a multiple that isapplied to a point value for each round. A multiple as used herein meansa value by which a point total (or unit total) is multiplied in order todetermine a final point (or unit) value for each player in a givenround.

The gaming application is configured to vary the multiple based on theprogression of the game, and/or the type of bids made during the roundof play. Because the gaming application varies the multiple based on theprogression of play, the possible increase of point allocation varieswith each successive bid. The “stakes” of winning can escalate or changebased on the sequence of bids. The gaming application is configured tomanage and implement the escalation and de-escalation of pointallocation during the rounds of play. As noted above, a startingmultiple for the first hand is set in block 418. In later stages of thegame, however, the multiple may be determined based one either A) one ormore characteristics of the electronic bid, or B) one or morecharacteristics of the electronic bid and the number of gameparticipants. As used herein, a characteristic of the electronic bid canbe a bid value or a bid level. The bid value is the value of theparticular character in the electronic bid initiated by a gameparticipant during a round of play. The bid level is the total quantityof particular characters in an electronic bid. In one example, themultiple can be 2× when the bid level is equal to three more than thetotal number of game participants. In such an example, if there are 4game participants and the bid level is “7”, the multiple for thatparticular round is “2×.” In another example, the multiple can be 3×when the bid level is equal to five more than the number of gameparticipants. In yet another example, the multiple can be 4× when thebid level is equal to seven more than the number of game participants.Accordingly, the multiple varies as the round of play, or successivebidding, progresses.

In one embodiment, the gaming application can vary the multiple as theround of play progresses by adjusting the multiple if certainpredetermined types of electronic bids are made. The multiple can beadjusted by an adjustment value that is based on at least one of: 1) thebid value, and 2) a bid level and the number of game participants. Theadjustment value can be “double,” “triple,” “quadruple,” or any otherfactor by which the multiple can be adjusted. In one example, themultiple is doubled when an electronic bid includes a bid value of “6”.In another example, the multiple can be quadrupled if the electronic bidincludes a bid value of “6”. Further, the particular character that isused to determine the adjustment value for the multiple can be anypredetermined character, such as a “7”, “9”, “A”, “L” or any othercharacter.

The multiples further limit point allocation from the losing bidder tothe other players and can increase point allocation to the winningbidder in a final hand. In one example, a losing bid loses no more thanthe starting multiple to each player. On the other hand, a winningbidder will be allocated points based on the final multiple from eachplayer. For instance, in a four player game where the starting multipleis 2×, a losing bid loses 6 points, with 2 points allocated from thelosing bidder to the remaining three players, regardless of the finalmultiple. If the final multiple reached 4×, however, a winning bidderwould be allocated 12 points—4 points from the remaining three players.However, in the example where the final multiple reached 4×, the losingbidder would only lose 6 points—2 points to each remaining player basedon the starting multiple of 2×. Accordingly, losing bids are constrainedby the incoming multiple and winning bidders garner the final multiplepayout, which is either the same or higher than the incoming multiple.The gaming application combines the multiples into one display field onthe user interface; the processor is configured to manage win/losspayouts according to the preceding logic.

Referring back to block 418, the processor determines the startingmultiple for each round of play during a game session. When a firstround of play is initiated, such as the round identified as Row A inFIG. 3, the starting multiple can be “1×”. The processor then executesan instruction to apply a multiple of “1×” to the initial round of play.If a particular round is not an initial round of play, the processorapplies the ending multiple to the next round of play, as noted in block450.

Once the electronic hands are assigned in block 418, process control istransferred to block 422. In block 422, the first player initiates anelectronic bid. The electronic bid is an indication of a total quantityof a particular character of the set characters at a particular valueamong each one of the electronic hands that was allocated to therespective plurality of game participants during a round. The electronicbid is a player's assessment of the number of characters “held” in eachelectronic hand by all players. In one example the electronic bid can bean indication that there are five (5) “7s” among all the electronichands associated with each game participant. In block 422, the firstplayer sets and initiates the electronic bid via the user interface,e.g. by engagement of input 543 (Level), input 541 (Value), and input540 (BID) as shown in FIG. 8. Initiation of the electronic bid via theuser interface causes the first players' computing device 20 to transmitthe electronic bid to the server-computing device 25. Theserver-computing device then causes the first player's electronic bid tobe displayed across each computing device. After the first playerinitiates an electronic bid, a subsequent player can initiate anelectronic bid or challenge the bid as further explained below. Forinstance, the next or second player can initiate an electronic bid viathe user interface, which causes the second players' computing device totransmit the electronic bid to the server-computing device 25. Theserver-computing device 25 then causes the second player's electronicbid to be displayed across each player's respective computing device. Incertain embodiments, the gaming application may require each subsequentbid to raise the level of the previous bid. For example, if 4 “4s” arebid, the next bid should be raised to five (5) “4s” or four (4) “5s.”When the electronic bid is initiated, process control is transferred toblock 426, as further discussed below. In some embodiments, equal orlesser bids compared to the previous bid are not permitted. In suchembodiment, the processor validates the bid by determining if the bid isgreater than the previous bid.

In certain examples, the game application can adjust point allocationsbased on the type of bid placed by the bidder. In initiating theelectronic bid in block 422, a bidding player can initiate a “none”electronic bid or “none-bid.” A “none” electronic bid is an electronicbid that includes an indication of a particular character that is absentfrom the player's electronic hand. A “none” bid succeeds when there arenone of that particular character among all other players. For instance,the computing device 25 may receive an indication that a gameparticipant is initiating a “none-bid.” The processor determines, amongall of the characters in each electronic hand, if the particular“none-bid” character is present. If none of the electronic handsincludes the “none-bid” character, then the point allocation isincreased by a predetermined amount. In one example, the predeterminedamount is 2n−6, where n is the number of players. However, in thisexample, a “none-bid” is invalid in a 2-person game, there is zeropayout in a 3-person game, and double payout in a 4-person game, etc.).The starting multiple of the round after the “none-bid” can be anyparticular multiple. In some examples, the starting multiple of theround after a “none-bid” is double, or “2×”. If the round is the final(e.g. the tenth) round of play, the starting multiple is doubled to“4×”. If, however, the processor determines that one or more of theelectronic hands includes the “none-bid” character, then the “none-bid”fails and the point allocation is not modified, remaining subject to theincoming multiple alone.

In another example, in the step of initiating an electronic bid asdescribed above in block 422, the initiated “none-bid” can result in a“hero” electronic bid, sometimes called a “hero-bid.” The “hero-bid” isa variation of the “none-bid” where the bidding player does not have theparticular character in the bid yet in the count the number ofcharacters present in the remaining electronic hands is still made. Ifthe processor determines that the particular character being bid isabsent from the bidding player's electronic hand and the count is stillmet among the remaining electronic hands, then the point allocation isincreased by a predetermined amount. In one embodiment, thepredetermined amount can be whatever multiple that bid would have earnedplus one. For instance, if the made bid would normally result in amultiple of “2×”, the “hero-bid” results in a “3×” multiple. Thestarting multiple of the round following a “hero-bid” can be anymultiple. In some examples, the starting multiple of the hand followingthe “hero-bid” is the same as in the “none-bid” case, “2×”, or in thefinal round of play, “4×”.

Referring now to block 426, the processor determines if the next, orsecond player, has initiated an electronic bid. If the processordetermines the second player has made an electronic bid, process controlis transferred to block 430. If, however, the processor determines thesecond player has not made an electronic bid, process control istransferred to block 434. In block 434, the second player has initiatedan electronic challenge. An electronic challenge is electronicindication that the electronic bid initiated by the previous player isfalse. For example, a player may initiate an electronic challenge thatthe electronic bid of four (4) “7s” is not correct or true. Processcontrol is transferred to block 430.

In block 430, the processor determines if each game participant hasinitiated an electronic challenge to the previous player's electronicbid. For instance, the server-computing device 25 may receive anelectronic challenge from each computing device associated with eachactive game participant. If the processor determines that less than allof the player's initiated an electronic challenge to the pendingelectronic bid, process control is transferred back to block 426 wherethe subsequent player initiates an electronic bid or an electronicchallenge. If, however, in block 430, the processor determines that eachplayer initiated an electronic challenge to the pending electronic bid,process control is transferred to block 438.

In block 438, the processor determines if the electronic challengeinitiated in block 430 is the first occurrence in a row where eachplayer initiated an electronic challenge of a bid. In block 438, if theprocessor determines that the electronic challenge initiated in block430 is the first occurrence in a row where each player initiated anelectronic challenge of a bid, process control is transferred to block442. But in block 438 if the processor determines that the electronicchallenge initiated in block 430 is the second consecutive occurrencewhere each player initiated an electronic challenge of a bid, processcontrol is transferred to block 446, where a count is made as describedbelow.

In block 442, the processor determines if the last player has initiatedan electronic bid. If the processor determines that the last playerinitiated the electronic bid, process control is transferred back toblock 426. In block 442, the processor can also determine, in responseto receiving the electronic challenge from each remaining computingdevice, if the active or playing computing device initiated a subsequentelectronic bid. The subsequent bid would be the bidding player's secondbid after being challenged all around by the other players. Second orsubsequent bids are typically required to raise at least one of bidlevel or bid value. As such, the subsequent electronic bid is anelectronic indication to raise at least one of the total quantity ofparticular characters and the particular value of the electronic bid. Inblock 442, if the processor determines that the player has not initiatedan electronic bid, process control is transferred to block 446. In thecircumstance where the bidding player has not initiated an electronicbid, the bidding player elects to force a count (e.g. by engagement ofuser interface input 548 as shown in FIG. 9). Accordingly, in certainexamples, the bidding player either raises the bid or forces a count.

In block 446, the processor determines the count and the outcome of theround. A count is a determination of the actual quantity of theparticular character at the particular value in the electronic bid thatis present in all of the electronic hands held by each player. Theoutcome is the allocation of points between players based on the resultsof the round. As noted above, the electronic bid is indication of thetotal quantity of the particular character at the particular value amongall electronic hands. The count can therefore be considered averification if the electronic bid is true. If the processor determinesthat the electronic bid is true, the playing bidder wins the round andreceives a point allocation for the win. If processor determines thatthe electronic bid is not true, the bidder loses the round and pointsare allocated from the playing bidder to the other players for the loss.The electronic bid is verified by comparing the electronic bid to theactual quantity and value of characters across all electronic hands. Inone embodiment, in block 446, the processor determines the actualquantity of the particular character at the particular value among eachelectronic hand held by each player. The processor compares the actualquantity of the particular character at the particular value to thetotal quantity of the particular character at the particular value asindicated in the electronic bid. The processor allocates a point valueto the bidding game participant if the actual quantity of the particularcharacter at the particular value is greater than or equal to the totalquantity of the particular character at the particular value in theelectronic bid, across all electronic hands. In addition, the processorallocates the point value from the bidding player to each of the otherplayers if the actual quantity of the particular character at theparticular value across all the electronic hands is less than the totalquantity of the particular character at the particular value in theelectronic bid initiated by the bidding player. The point value asdetermined in block 446 can be adjusted by the multiple for theparticular hand as described above with respect to block 442 (where thefinal multiple is for that hand). Furthermore, the point values can bedisplayed via the user interface for each round of play (see referenceoutput icon 549 in FIGS. 8 and 9). In addition, in block 446, theallocated point values for each player are compiled.

It should be appreciated that progression of the game through blocks430, 442 and 446 can proceed in accordance with an alternativeembodiment. In one alternative embodiment, in block 446, in response toreceiving at least two consecutive electronic challenges concerning theelectronic bid from at least two respective computing devices, theprocessor can determine the actual quantity of the particular charactersof the set of characters at the particular value among each electronichand. The processor can proceed with a comparison and subsequentallocation of points based on the results of the comparison, similar tothe process as described above. In accordance with the alternativeembodiment, however, an electronic challenge from each one of the otherplayers may not be required. For example, when the processor receives afirst electronic challenge from one of the computing devices and asecond electronic challenge from another computing device, the processorcan 1) determine the actual quantity of the particular characters at theparticular value among each one of the electronic hands, 2) compare theactual quantity and the total quantity of the particular characters atthe particular value, and 3) allocate the points to or from the biddingplayers. The number of electronic challenges required before theprocessor initiates the count can be two challenges from two otherplayers, even if there are 4, 6, 8 or 10 other players.

When the processor has determined the count and outcome as noted above,process control is transferred to block 448. In block 448, the processorcompiles the allocated point values for each participant and stores thepoint values in the computer memory. More specifically, the processorallocates the point values for each player as gains and losses andstores the gains and losses for each participant. Furthermore, for eachround of play, the gains and losses are displayed on the computingdevice at output portion 549. In one example, the user interface candisplay the gains as point value in green (signed +) and losses as apoint value in red (signed −). In any event, the processor is configuredto cause the gains and losses to be stored in memory until the resultsof each session are posted on the “Sheet” screen (see 572 in FIG. 11)and further detailed below. Process control is transferred to block 450.

In block 450, the processor determines the starting multiple for thenext round of play. In block 450, in the event that a particular roundis not an initial round of play, the processor applies the endingmultiple from the previous round of play to the next round of play. Inother words, for one round, the ending multiple can be the startingmultiple for the next round of play. More specifically, the processorexecutes an instruction to cause the gaming application to apply theending multiple from the previous round of play to second, or subsequentrounds of play. For example, if the ending multiple in the first roundof play is “2×”, then the starting multiple in the second round of playis “2×”. If, however, the processor determines the round of play is thefinal round in the sequence of play, the processor increases themultiple from the previous round of play by a predetermined factor. Inone example the predetermined factor is 2. In such an example wherethere are ten total rounds of play in a game session, if the endingmultiple on the ninth round of play is “4×”, then the starting multipleon the tenth round of play is the product of “4×” and 2, resulting in astarting multiple of “8×.” The predetermined factor may be any wholenumber greater than 1. For example, the predetermined factor can be 2,3, 4, 5, . . . 10, . . . 20 up to any particular whole number n. Inalternate embodiments, however, the predetermined factor can befractional value, such as 1.10, 1.20, 1.30 . . . 2, 2.10, 2.20, 2.30 . .. up to 3, 3.10 or more. Further, in block 450 the processor candetermine the multiple applied to the last bid (as in block 442 wherethe final multiple is for that hand). Throughout the sequence of play,the gaming application is configured to verify the multiple of theround. The gaming application is configured to display the verifiedmultiple of the round. If necessary, the multiple can be adjusted aftereach bid (as in blocks 422, 426, and 442). The verification starts atthe incoming multiple and is adjusted based on the bid value, bid level,and the number of players, as described above. Process control istransferred to block 452.

In block 452, the processor determines if the final round of play hasbeen completed. For example, where the sequence of play includes tenrounds, the processor determines if the tenth round of play has beencompleted. If the processor determines that the final round of play hasnot been completed, process control is transferred back to block 422,where the first player (bidder of record from the previous hand)initiates an electronic bid to start a new round of play. If theprocessor determines that the final round of play has been completed,process control is transferred to block 456. In block 456, the pointvalue for each participant for each round of play is displayed via thegraphical user interface as a “Sheet” screen (see 572 in FIG. 11).Process control is transferred to block 460. In block 460, the processordetermines if another game including a sequence of rounds of play isinitiated. For instance, any number (or all) of the player's computingdevices can initiate a new game. Process control is then transferredback to block 418, where new electronic hands are associated with eachplayer's computing device. If, in block 460, the processor determinesthat no further games or rounds of play are initiated, the gamingapplication terminates in block 464.

FIGS. 5 through 11 illustrate exemplary displays of a graphical userinterface 500 running on each computing device during a game. FIG. 5illustrates an initial flash screen 505 for the gaming application asdescribed herein. FIG. 6 illustrates a user interface screen 509, whichincludes a frame 510 used to initiate a multiple player game via thegaming platform 30. The frame 510 can include and outputs 512, agraphical representation of the player associated with the computingdevice. The frame 510 can include an input portion 514, selection ofwhich can invite additional players or others to join a game or downloadthe gaming application. An additional input portion 516 can be used tolaunch the gaming application on the computing device 20. Selection ofinput portion 516 causes the user interface to display screen 509 andframe 520 illustrated in FIG. 7.

As shown in FIG. 7, displayed frame 520 includes tabs 502, 504, 506 and508. Selection of a particular tab 502, 504, 506 and 508 causes the userinterface 500 to pull up various frames for playing and/or managing thegame. Selection of tab 502 can cause the frame 510 for invitingadditional players (see FIG. 6) to display on screen 509. Selection oftab 504 causes the user interface to display an active game sessionsframe 520. Selection of tab 506 causes the user interface to display aSheet frame 570 (FIG. 11). Selection of tab 508 causes the userinterface to display a settings frame (not shown).

Continuing with FIG. 7, the active sessions frame 520 includes listingsof games sessions 522 and 524. The user or player can select session 522and 524 to join either of the active game sessions. Selection of session524 may cause the user interface to display frame 530 as shown in FIG.8.

FIG. 8 is a view of the graphical user interface displaying frame 530that allows players to participate in a round of play during a session300. Frame 530 includes various outputs regarding the game. Forinstance, frame 530 includes a bidder identifier 532, round of play 310,the current electronic hand 350, and multiple 534. Other informationincludes a listing 538 of each players previous electronic bids andcurrent bid. During a hand, the current bid is a combination of what isdisplayed in the bid level field 543 and bid value field 541 (e.g., thecurrent bid is the number of the particular character indicated). Thebid level field 543 shows the quantity of the specific character shownin the bid value field 541. The frame 530 includes several inputsassociated with initiating an electronic bid, such as a slide features544 a, 546 a and +/− inputs 544 b, 546 b which can be used to increaseor decrease the magnitude of the bid level and bid values as illustratedin bid level field 543 and bid value field 541. Input button 540 can beused to submit a bid. Additional input 542 allows a player to challengeanother player's bid. Input 352, represented in dashed lines aroundelectronic hand 350, can be used to invoke a window 580 that displaysinformation concerning the current session. The window 580 is furtherdescribed below. The frame 530 includes indicator field 543 for theselected bid level and indicator field 541 for the selected bid value.Furthermore, the frame 530 includes point identifier indicator 549,identified as “Slip PL.” The point value indicator 549 displays the gameplayer's accumulated point value. In the event the game player wins abid or challenge, the processor allocates the point value to the gameplayer, and further causes the user interface to display the accumulatedpoints at point value indicator 549. In one example, if the point valueis positive, the point value indicator and value may be displayed with apositive sign (+) in the color green. If, however, the game player losesa bid or challenge, points are removed from that players pointaccumulation. In one example, if the point value is negative, the pointvalue indicator and value may be displayed with a negative sign (−) inthe color red. Any other colors could be used as needed to displaypositive and negative values.

FIG. 9 shows the graphical user interface 500 displaying frame 550 withadditional inputs for a count option 548. The frame 550 includes outputand input portions that are similar to those shown in frame 530illustrated in FIG. 8. For instance, the frame 550 includes a bidderidentifier 532, round of play 310, the current electronic hand 350, andmultiple 534, which in FIG. 9 has been changed to “2×” from the “1×”shown in FIG. 8. Other information includes the bid listing 538 andpoint value indicator 549. Though not specially called out in FIG. 9,the frame 550 would also include inputs 544 a, 544 b, 546 a, 546 b.

FIG. 10A shows the graphical user interface 500 displaying screen 509and a scrollable window 580 invoked by the player. FIG. 10B is adetailed view of a portion of window 580 shown in FIG. 10A. As notedabove, a player invokes window 580 by depressing electronic hand inputbutton 352 (see FIG. 8). Pressing the window 580 coupled with upward ordownward gestures cause the window 580 to scroll up or down in directionalong arrow A shown to the left of the screen 509. The window 580displays information concerning the game session 300 and each electronichand 350 established for that game session 300. As illustrated, thewindow 580 displays played hands 612, 614, 616, and 618 numberedconsecutively and shaded with a particular color. As illustrated, thecolor is grey although any color could be used to show played hands. Thewindow 580 also displays un-played hands 624, 626, 628 and 630 inanother color that contrasts with the color a played hand is displayedin. As illustrated, the unplayed hands are shown in green although anycolor could be used. The current hand 620 is shown in green, numbered,and underlined while also maintaining its position at the top of thedisplay. Thus, the current hand is shown as reference numbers 622 and620 in FIG. 10A. Each hand (played or unplayed) displays a rowidentifier 312, the electronic hand 350, and incoming multiple 534 for aplayed or current hand. For unplayed hands, only the row identifier 312is illustrated to the right of the electronic hand 350. Row identifier312, hand 350 and multiple 534 are shown with respect to current hand622. Played hands may include a bidder identifier 532, such as bidderidentifier 532-2 for played hand 612 and bidder identifier 532-5 forplayed hand 618. As shown in FIG. 10B, each played hand includes a rowidentifier 312 associated with the row of played hands discussed aboveand shown in FIG. 3. For instance, the played hand 618 includes a rowidentifier 312-J, indicating that the characters comprising played hand618 is based on Row J of game session 300. Similarly, unplayed had 626includes row identifier 312-K, indicating that the characters comprisingunplayed hand 626 is based on Row K of game session 300. Current hand620 includes row identifier 312-L, indicating that the characterscomprising current hand 620 is based on Row L of game session 300.Furthermore, the window displays the starting multiple for each playedhand. For instance, played hand 618 includes multiple 534 p shown as“2×.” Furthermore, the bidder identifier 532-5 is the bidder associatedwith played hand 618. In addition, for each played hand, the window 580displays point losses 549 a and point gains 549 b. The current hand 620includes the incoming multiple 534 c associated with that hand. Thewindow 580 can be configured as an in-app purchase. Selection of input352 can invoke a method of obtaining payment and/or purchaseauthorization.

FIG. 11 shows the graphical user interface 500 displaying frame 570.Frame 570 includes a sheet 572 that displays player identifiers 532, theallocated point totals 576 for each player identifier for eachparticular game session completed among the group of players. The sheetalso includes a value 578 that is a total for all the allocated pointsfor each player identifier for each session. During play, each playercan select tab 506 to review point totals.

The gaming application can be configured to cause the display of otherinformation regarding game sessions and electronic hands. For instance,in one embodiment, the processor can be configured to determine the bidprobability. The bid probability is a mathematical likelihood ofachieving a bid given the number of characters in a hand and the totalnumber of players. The graphical user interface can cause the determinedbid probability to be displayed in an additional field, window, or tab(not shown). Bid probability can be configured as an in-applicationpurchase. Selection of input, such as “Bid Probability Gauge” (notshown), can invoke a method of obtaining payment and/or purchaseauthorization. Upon payment authorization, the bid probabilityfunctionality is operable within the gaming application.

It will be appreciated that the foregoing description provides examplesof the disclosed system and method. However, it is contemplated thatother implementations of the disclosure may differ in detail from theforegoing examples. All references to the disclosure or examples thereofare intended to reference the particular example being discussed at thatpoint and are not intended to imply any limitation as to the scope ofthe disclosure more generally. All language of distinction anddisparagement with respect to certain features is intended to indicate alack of preference for those features, but not to exclude such from thescope of the disclosure entirely unless otherwise indicated.

We claim:
 1. A method for implementing a game among a plurality ofcomputing devices, the plurality of computing devices associated with arespective plurality of game participants, the method comprising thesteps of: associating an electronic hand with each one of the pluralityof computing devices for a round of play, each electronic hand includinga set of characters, and each character having a value; receiving anelectronic bid from a first computing device of the plurality ofcomputing devices, wherein the electronic bid is an indication of atotal quantity of a particular character of the set characters at aparticular value among each electronic hand associated with therespective plurality of computing devices; receiving an electronicchallenge concerning the electronic bid from each remaining computingdevice other than the first computing device of the plurality ofcomputing devices; determining an actual quantity of the particularcharacter at the particular value among each one of electronic handsassociated with the respective plurality computing devices; in responseto receiving the electronic challenge from each of the remainingcomputing devices of the plurality of computing devices, comparing theactual quantity of the particular character at the particular value tothe total quantity of the particular character at the particular valuein the electronic bid; allocating a point value to the game participantassociated with the first computing device if the actual quantity of theparticular character at the particular value is greater than or equal tothe total quantity of the particular character at the particular valuein the electronic bid, wherein the point value is adjusted by a multiplethat is based on at least a bid level, wherein the bid level is thetotal quantity of the particular character in the electronic bid; andcausing the multiple to vary for each round of play based on at leastone of A) the bid level of the electronic bid and the number of gameparticipants, and B) a bid value, wherein the bid value is the value ofthe particular character.
 2. The method of claim 1, further comprisingthe step of allocating the point value from the game participantassociated with the first computing device to each of the other gameparticipants if the actual quantity of the particular character at theparticular value is less than the total quantity of the particularcharacter at the particular value in the electronic bid.
 3. The methodof claim 1, wherein in response to receiving the electronic challengefrom each remaining computing device, further receiving from the onecomputing device a subsequent electronic bid, the subsequent electronicbid being an electronic indication to raise at least one of the totalquantity of particular characters and the particular value.
 4. Themethod of claim 1, wherein in response to receiving a first electronicchallenge from a first one of the plurality of computing devices and asecond electronic challenge from a second one of the plurality ofcomputing devices, determining the actual number of the particularcharacters at the particular value among each one of the electronichands.
 5. The method of claim 1, further comprising the steps of:compiling a game session that includes a plurality of rounds of play,each round associated with a plurality of the electronic hands; for eachround, allocating each electronic hand to each one of a respectivecomputing device; and determining the total point values allocated toeach game participant during each round.
 6. The method of claim 5,further comprising the step of determining a sequence of the pluralityof rounds to be played based on a quantity of a particular characteramong the plurality of the electronic hands during each round.
 7. Themethod of claim 5, further comprising the step of doubling the pointvalue allocated to the one game participant that initiated theelectronic bid when the value of the particular characters in theelectronic bid is the same as a predetermined value.
 8. The method ofclaim 7, wherein the value of the character is one of the numbers 1, 2,3, 4, 5, 6, 7, 8, 9, and 0, and the predetermined value is
 6. 9. Themethod of claim 8, wherein 0 has the greatest value of each of thenumbers between 1 and
 9. 10. The method of claim 8, wherein 0 has thelowest value of each of the numbers between 1 and
 9. 11. The method ofclaim 1, wherein a game session includes a plurality of rounds, eachround including the plurality of the electronic hands associated witheach game participant, wherein the method includes the step of causingthe ending multiple of a first round of to be applied to a second roundthat is subsequent to the first round.
 12. The method of claim 11,wherein the method includes the step of doubling the multiple applied tothe second round in the game session by a predetermined amount when thesecond round is the final round in the plurality of rounds.
 13. Themethod of claim 1, further comprising the steps of: receiving anone-value electronic bid from one of computing devices, the none-valueelectronic bid being an electronic indication that no electronic handamong each one of the plurality of electronic hands includes aparticular character of the set of characters; and determining if noneof the other of the plurality of the electronic hands associated withthe other computing devices include the particular character of the setof characters; and if none of the other of the electronic hands includethe particular character, adjusting the point value of the one gameparticipant associated with the one computing device by a predeterminedamount, the predetermined amount being based upon the quantity of gameparticipants.
 14. The method of claim 13, wherein the predeterminedamount is twice the number of game participants less the value of
 6. 15.The method of claim 13, further comprising the step of adjusting thepoint value of the one game participant when the particular character ofthe set of characters is not present in the electronic hand of the onegame participant associated with the one computing device that initiatedthe electronic bid yet is still present in the remaining electronichands associated with the other game participants.
 16. The method ofclaim 1, further comprising the step of causing the electronic hand tobe displayed via a user interface on the computing device associatedwith each respective game participant.
 17. The method of claim 1,further comprising the step of causing the multiple for a first round ofthe plurality electronic hands to be displayed on each computing device.18. The method of claim 1, wherein all of the points allocated to thegame participant that initiated the electronic bid is allocated fromeach of the remaining game participants.
 19. The method of claim 1,wherein a game session includes a plurality of rounds and each round isassociated with a plurality of the electronic hands, wherein the methodincludes the step of associating the electronic hands with therespective plurality of computing devices in a random sequence among therounds.